Efficient, Unified, and Scalable Performance Monitoring for Multiprocessor Operating Systems

Programming, understanding, and tuning the performance of large multiprocessor systems is challenging. Experts have difficulty achieving good utilization for applications on large machines. The task of implementing scalable systems such as an operating system or database on large machines is even more challenging. And the importance of achieving good performance on multiprocessor machines is increasing as the number of cores per chip increases and as the size of multiprocessors increases. Crucial to achieving good performance is being able to understand the behavior of the system

Strata-Various: Multi-layer Visualization of Dynamics in Software System Behavior

Current software visualization tools are inadequate for understanding, debugging, and tuning realistically complex applications. These tools often present only static structure, or they present dynamics from only a few of the many layers of a program and its underlying system. This paper introduces "PV", a prototype program visualization system which provides concurrent visual presentation of behavior from all layers, including: the program itself, user-level libraries, the operating system, and the hardware, as this behavior unfolds over time. PV juxtaposes views from different layers in order to facilitate visual correlation, and allows these views to be navigated in a coordinated fashion. This results in an extremely powerful mechanism for exploring application behavior. Experience is presented from actual use of PV in production settings with programmers facing real deadlines and serious performance problems

Providing a Linux API on the scalable K42 kernel

Abstract K42 is an open-source research kernel targeted for 64-bit cache-coherent multiprocessor systems. It was designed to scale up to multiprocessor systems containing hundreds or thousands of processors and to scale down to perform well on 2-to 4-way multiprocessors. K42's goal was to re-design the core of an operating system, but not an entire application environment. We wanted to use a commonly available interface with a large established code base. Because Linux is open source and widely available, we chose to support its application environment by supporting the Linux API and ABI. There were some interesting complications as well as advantages that arose from K42's structure because our implementation of the Linux application environment was done primarily in user space, had to interface with K42's object-oriented technology, and used fine-grained locking. Other research systems efforts directed at achieving a high degree of scalability and maintainability exhibit similar structural characteristics. In this paper we present the motivation behind K42, including its goals and overall structure, and describe its system interface. We then focus on the required infrastructure and mechanisms needed to efficiently support a Linux application environment. We examine the lessons learned of what was advantageous and what was disadvantageous from K42 in implementing the Linux API and ABI

K42 Overview

K42 is an open-source research kernel for cache-coherent 64-bit multiprocessor systems. K42 focuses on achieving good performance and scalability, providing a customizable and maintainable system, and being accessible to a large community through an open source development model. To that end, K42 fully supports the Linux API and ABI and uses Linux libraries, device drivers, file systems, and other code. In this paper we present a brief overview of K42, describe the goals of K42 and the core technologies we used to achieve those goals. More detailed descriptions of specific technologies and OS services are available in separate white papers

Memory Management in K42

This document describes the kernel mechanisms that support virtual memory and the protocols used to communicate with clients that suffer page faults and with file servers that provide paging I/

Jonathan Appavoo

Introduction and Motivation In k42 we partition the scheduler between the kernel and application-level libraries. The K42 kernel schedules entities we call dispatchers, and dispatchers schedule threads. A process consists of an address space and one or more dispatchers. Within an address space, all threads that should be indistinguishable as far as kernel scheduling is concerned are grouped under one dispatcher. A process might use multiple dispatchers for two reasons: to attain real parallelism on a multiprocessor, or to establish differing scheduling characteristics (priorities or qualities-of-service) for different sets of threads. A process does not need multiple dispatchers simply to cover page-fault, I/O, or system-service latencies, or to provide threads for programming convenience. These requirements can be met using multiple user-level threads running on a single dispatcher. The dispatcher abstraction allows individual threads to block for page faults or system services wi

Jonathan Appavoo

this paper we present a brief overview of K42, describe the goals of K42 and the core technologies we used to achieve those goals. More detailed descriptions of specific technologies and OS services are available in separate white paper